1. Field of the Invention
The present invention relates generally to the field of computer interconnection and networking, and more particularly to an improved method for monitoring, identifying the configuration of and managing extremely large computer networks. Still more particularly, the present invention provides a method and system for measuring a transaction response time on a computer network.
2. Description of the Related Art
The interconnection of computers into large operational groups, simulating semi-independent but concerted action of human groups, is becoming increasingly prevalent, and increasingly important. With the introduction of powerful small computers, it has become recognized that decentralized computing is more efficient and cost effective than older centralized (mainframe) computing methods. Furthermore, a growing number of uses for computers appears to be the trend for the present and the future, with many of these uses requiring or involving communication and interaction between computers, both in localized areas and in remote locations. The method which is generally recognized today as being most efficient is to interconnect various independent computing units and peripherals (of any of a huge number of types and functions) into operational groupings known as "networks". Networks come in wide varieties, as well, being defined by the bus type (e.g. Ethernet, Token Ring, etc.) or by the extent of the configuration (e.g. local area, enterprise, metropolitan and global networks). All of these require management and optimization to best serve the needs of the user.
Only a short whole ago even the most complex computer networks were small enough to be fairly easily managed. A typical Local Area Network ("LAN") was situated in a single building or office and contained a relatively small number of workstations, with a single server controlling everything. A person, known as a "network manager", would be fully familiar with all of the components and programming and would be able to recognize situations and problems very efficiently, based on this familiarity. However, even though LANs remain common, today's computer networks are often so expansive and varied that a network manager has difficulty even keeping track of all of the devices connected to the network, let alone determining an optimal configuration for such a network. Increasingly, networks are connected to other networks to form expansive and complex computer interconnection schemes, sometimes having even a worldwide scope. In such complex networks, changes, due to failed or added equipment, new users, or changing applications as a few examples, may be made at the far reaches of the computer network on, essentially, a daily basis.
As one skilled in network management will realize, a primary task is to keep track of the actual configuration of the network and, following that, to reconfigure or otherwise optimize or "tune" the network, as necessary, so as to minimize problems and maximize the utilization of resources. Having recognized a need for tools to assist network managers in the task of monitoring large networks, inventors have developed several tools for the purpose.
A Simple Network Management Protocol ("SNMP") standard has been developed, and continues to be refined, for defining types of data necessary for network management. A part of the SNMP is a Management Information Base ("MIB"), which includes information relating to the number of processors running on a network, number of collision packets detected, and the like. A Remote Network Monitoring Information Base ("RMON") is a standard protocol for use in networking management and related activities. U.S. Pat. No. 5,315,580 issued to Phaal teaches a network monitoring device and system for monitoring the activity on a network, such as might be used to collect data according to the RMON standard. The Phaal system includes means for selecting a theoretically representative number of message packets and a processing means for collecting data related to such message packets.
An Open Systems Interconnection ("OSI") model describes a way to encapsulate data in packets in an effort toward standardizing data packet forms. The OSI standard divides packet information into seven general layers (see Table 1, below). The layers generally refer to the sequence of data information within each packet. The OSI reference model is utilized to generally indicate the type of information contained in data packets sent over network systems, but is not universally utilized, nor is the use consistent for all types of networks. To the inventor's knowledge, however, the OSI model has not been implemented in its entirety. Indeed, data portions which fall within the higher levels of the OSI standard are located and/or formatted quite differently according
TABLE 1 ______________________________________ OSI Reference Model Layer Number Content ______________________________________ 1 Physical 2 Data Link 3 Network 4 Transport 5 Session 6 Presentation 7 Application ______________________________________
to device and network protocol. The OSI model does, however, provide a reference that is generally accurate.
The RMON protocol deals, generally, with information contained in the second OSI layer types. Other layers, as will be discussed later, include information reflecting other characteristics of the data packet.
While the prior art systems are relatively effective at informing a network manager about the configuration of a network, there is a great paucity of information concerning the efficiency of the network and even less information which might help the manager in improving such efficiency. Moreover, the inability to integrate information, which might otherwise be helpful, from different device types has presented an even more formidable barrier to the manager's tasks.
To the inventor's knowledge, prior to the present invention, no means has existed in the art for remotely obtaining information from a widely dispersed network having therein a variety of device types and sub-network configurations, which information will be sufficient to inform a manager not only about the configuration of the network, but also about the operation, efficiency, and problem areas within the network. All prior methods and means by which network managers could obtain information about the network could obtain only superficial data about the network configuration and/or could not function to full effect where various equipment types (such as both Apple.TM. computers and IBM.TM. compatible computers) and/or various sub-network types (such as Novell.TM. and AppleTalk.TM.) are interconnected. Much room exists for more efficient, more inclusive and more user-friendly systems for monitoring and managing complex network arrays.
A type of information which is particularly helpful to a network manager in improving network efficiency is the transaction response time of an application distributed throughout a widely dispersed network. Portions of such an application are usually executed on device types within the network such as personal computers (PC) or workstations, and other portions of the same application are usually executed on other network device types such as servers. The application is typically of the data-acquisition type involving a client PC sending a transaction to a server in order to access and utilize data stored on the server. The total response time for such a transaction is equal to the difference between the point in time a user initially sends a screen of data to the server and the point in time at which the user receives a new screen of data. Currently, there are only a few tools for measuring the transaction response time, and none of these tools, to the inventor's knowledge, are "non-intrusive" tools. A "non-intrusive" tool is one which does not require the applications on the network to be modified and re-compiled in order for transaction response times to be measured.
An example of an "intrusive" tool for measuring a transaction response time is described in a document called "Application Response Measurement, API Guide," published jointly by Hewlett-Packard Co. and International Business Machines, Inc., in June 1996. As stated on page iii of the guide, it is "intended for the application programmer who wants to know how to instrument an application for transaction monitoring using the standard Application Response Measurement (ARM) API function calls." This tool requires each application on the network to be modified and re-compiled to include special functions for sending a token packet on the network which, when detected, assists in measuring a transaction response time. Thus, this tool requires significant changes to all applications on the network in order for transaction response times to be measured. Such changes may cause subsequent problems in the applications since new errors and software bugs may be introduced during the necessary modifications and re-compilations of the applications.